First pass turned every step into a paragraph with parenthetical
rationale and warning callouts; the result rendered as a vertical
wall of prose, monospace sub-bullets full of long sentences, and a
3-card post-validation panel that re-stated info from the setup
list. User feedback: "UX is bad."

This trim:

  • Reduces setup from 8 long steps to 6 single-line imperatives.
    Each step says WHAT to click; rationale ("required so MSAL
    client_credentials can mint the Graph token") is removed —
    users don't need that to follow the click path.
  • Reserves the `details` slot (monospace) for things that should
    actually be monospaced: an enum value, a permission name.
    Prose details made the layout feel like a code listing.
  • Moves the messaging endpoint, ngrok instructions, and Teams
    app `.zip` install OUT of setup and INTO the post-validation
    `TeamsWebhookMode` panel — they happen AFTER credentials
    validate, so putting them in the upfront list both bloated
    setup and skipped the natural workflow break.
  • Drops the redundant Channel.ReadBasic.All card from
    TeamsWebhookMode — it's already in setup step 6, and
    repeating it implied "do this again" rather than "review."
  • TeamsWebhookMode is now 2 cards instead of 3, with shorter
    body copy.

Verified:
- `npx tsc --noEmit` on `web/` clean
- Web image rebuilt and deployed; localhost:3000 returns HTTP 200
- The instruction list now scrolls minimally above the Display
  Name input

Confidence: high
Scope-risk: narrow — UI text only.
Directive: the `details` array on a setup-step instruction renders
  in monospace. Use it for code-shaped values (paths, enum values,
  command snippets), NEVER for prose explanations.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

…es supported

User-reported gaps after the first trim:
  • The setup steps explained creds/Azure but never told users
    HOW to get a public webhook URL (ngrok) or WHERE to enter the
    bot URL — they were left guessing whether we needed it as a
    wizard field. We don't (bot listens on a fixed path), but the
    setup list must say so.
  • The App Type hint read as "we only support SingleTenant" when
    in fact the select offers both and the SDK accepts either.

Changes:
  • Setup step 2 (new): "Expose this bridge over HTTPS, then set
    the Bot's Messaging endpoint to your URL + /api/teams" with
    mono details for `ngrok http 3001` and the URL pattern. This
    surfaces what was previously buried in the post-validation
    panel.
  • Setup step 1 detail updated to "SingleTenant (recommended) or
    MultiTenant" so the choice is visible upfront.
  • App Type hint rewritten to lead with "Both modes are
    supported" — no longer reads as a restriction.
  • TeamsWebhookMode collapses from 2 cards to 1: just the .zip
    app install. The endpoint card moved to the setup list above;
    keeping it here would have been redundant.

Verified:
- `npx tsc --noEmit` on `web/` clean
- Web image rebuilt and deployed

Confidence: high
Scope-risk: narrow — wizard text only.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

…UID checks

The wizard's Validate step previously only constructed the Teams adapter
(format check) — a typo'd App ID or wrong secret passed "validation" and
only failed later when channel enumeration silently returned []. Now:

- bridge.ts handleValidateAdapter actually mints a Graph token via MSAL
  and classifies AADSTS / unauthorized_client / invalid_client errors as
  credential failures; non-auth probe failures (403 consent, network)
  soft-accept with a pointer to Channel.ReadBasic.All admin consent.
- ConnectionWizard validates App ID / Tenant ID against the AAD GUID
  shape client-side, renders inline errors, and gates the Validate
  button until they pass.
- Teams is no longer treated as webhook-only: the Channels step renders
  the real Graph-enumerated channel list (depends on #206).

Verified live: a real Teams connection was created through this exact
flow today (channel discovery + message history sync working).

Constraint: validation must not require the messaging endpoint to be live yet
Rejected: server-side-only GUID validation | users deserve inline feedback before a round-trip
Confidence: high
Scope-risk: narrow
Not-tested: MultiTenant validation path against a real multi-org token

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

… filename

The loose manifest.json referenced botId eefc03cb-… which does not exist
in any Azure tenant (stale id from an early registration attempt), and
was missing webApplicationInfo + RSC permissions — a package built from
it could install but never read channel history. The actual working
package (built via teams CLI) used the correct id but generic
"Developer/example.com" branding.

Merge the two: correct id (fb24e83f-…), manifest schema 1.25, RSC perms
(ChannelMessage.Read.Group, ChatMessage.Read.Chat), personal tabs, and
Beever AI branding. Bump to 1.0.3 (dev portal auto-bumped to the same).

build-package.mjs now writes beever-atlas-teams.zip (the name actually
used/uploaded everywhere) instead of beever-atlas-bot.zip; .gitignore
updated to match so the build artifact stays untracked.

Constraint: dev-portal catalog already at version 1.0.2 — local manifest must be ≥1.0.3
Rejected: tracking the built zip in git | reproducible artifact, build script exists for that
Confidence: high
Scope-risk: narrow
Directive: botId must equal the AAD app id fb24e83f-… — never regenerate it independently

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>